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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



The present rapid development of a diversity of new applications and application environments for mobile usage creates 
a complexity of previously unseen proportions that the UE has to handle. These applications and application 
environments co-exist and execute independently in the UE, and thus have the potential to interact with each other in a 
way that could be detrimental to the positive user experience and sense of user control of the UE. There is a need to 
control and manage the total applications/interfaces environment and MT resources so as to produce a conceptually 
consistent and logically whole and integrated user experience. 

The present document outlines a generic model for the interaction between these applications. It further specifies a set 
of basic principles and requirements for these applications to co-exist on the UE. This specification may also result in 
presenting to the user a coherent user experience. 

The present document's purpose is not to categorise the applications peripherals, but to try to structure the events that 
are internal and external to, and has to be handled by, the MT Core Functions. This means that the structure or grouping 
of the events should be made from a MT centric perspective. Some applications run on the UE side have counterparts in 
the network. The present document addresses the interactions within the UE. 

The User Equipment functional model used in this specification is defined by the model included in 23.101 [8]. 
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UE 



Figure 1 : Functional Model for the User Equipment 
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Scope 



The present document defines the principles for scheduHng UE resources and controlhng UE interactions and resolving 
conflicts between independently running applications in different application execution environment (e.g. MExE, 
USAT etc.) and internal and external peripherals (e.g. infra-red, Bluetooth, USIM, radio interface, MMI, memory etc.). 

The present document is divided in two parts: clause 4 defines a framework for event handling. Clause 5 addresses 
some specific issues. 

Annex A contains an informative background to the problem area. 
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The following documents contain provisions which, through reference in this text, constitute provisions of the present 
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• References are either specific (identified by date of publication, edition number, version number, etc.) or 
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Release as the present document. 
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[7] 3GPP TS 22.038: "USIM/SIM Application Toolkit (US AT/SAT); Service description; Stage 1". 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in the referred documents and the following 
apply: 

call: voice and data calls, USSD, SMS, fax, GPRS calls, supplementary services, etc. 

preferences: includes authorisations, priorities, options, etc. 

authorisation: permission to set up and or receive any call or only certain types of call and access rights to user data 

MX Core Functions: software functions that contain the central logic for the MT, including for instance the scheduling 
of events 
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3.2 Abbreviations 

For the purposes of the present document the following abbreviations apply: 

ME: Mobile Equipment 

MExE: Mobile Execution Environment 

MM: Mobility Management 

MT: Mobile Termination 

RR: Radio Resource 

UE: User Equipment 

USAT: USIM Application Toolkit 

WAP: Wireless Application Protocol 



Principles for the Framework 



The model presented in annex A defines a framework specifying principles for event handling, with the focus on issues 
related to application interaction. Principles for the framework are given below, using the stated definitions. The list is 
not necessarily complete. 



4.1 Basic principles 



1. Irrespective of the principles given below, emergency calls shall override all other calls. 

2. The MT is the central resource and schedules internal and external entities according to the user's preferences and 
external environment. 



4.2 User requirements 



1. The user shall have the capability to make the ultimate decisions as elaborated below. Additionally, in the case 
where an UE is unmanned, none of the issues below shall render the UE inoperable such that it requires manual 
intervention locally at the UE to restore its use. 

2. The user shall have the capability of selecting preferences interactively and/or via prior set-up in one or more user 
profiles. These shall be valid on a global or on a per application basis. The user's preferences shall be retained even 
in the event of loss of power. 

Preferences can be selected for an application when it is installed, or at any other time thereafter. 

Preferences, notably but not exclusively the priorities, can be modified at any time and this shall have effect at the 

earliest possible opportunity thereafter. 

3. The user shall have the capability to modify authorisations assigned to applications. These shall be valid on a 
global or on a per application basis in one or more user profiles. 

4. The user shall have the option to be advised to what extent an application has been authenticated at installation- 
time, and prevent the application from being installed based on this advice. 

The user shall have the option to be advised about the integrity of an application at installation-time, and prevent 
the application from being installed based on this advice. 

5. The user shall have the capability to abort or suspend any on-going call that has been set up automatically by an 
application. 

6. The user shall have the capability to require that the UE request permission from the user for individual calls, sets 
of calls (for instance all calls by a certain application) or all calls. The user shall have the capability to request the 
UE to record information on individual calls, sets of calls or all calls. 

7. The user shall have the capability to distinguish which entity/application caused a specific event. The UE uses this 
information to support the user's preferences. The UE shall be able to inform the network of entity/application at set 
up time to support trace-ability when a call is set up. 

8. The user's privacy shall be protected. Access to user data (including user profiles and any personal information in 
the UE) and audio functions (this would prevent for instance a mechanism that allows eavesdropping) shall not be 
possible without the user's prior permission. 
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9. The user shall have the capability to request from the UE which applications are present in the MExE environment 
and the (U)SIM, and whether they are running. The user shall also have the capability to request from the UE the 
status of other interfaces as shown in Figure 1, where implemented. 

4.3 Specific requirements on applications 

1. An application shall not assume that it is the only one active. For example where several applications use the same 
interface the application and/or the protocols used over the interface must be able to handle contention. 

2. An application shall not interfere (terminate, suspend or degrade) with on-going calls set up by another application 
without authorisation from the user. For certain combinations of call (e.g., voice/data and USSD messages), 
interference can happen resulting in a level of degradation. 

3. An application shall not assume that it has priority over another application, and shall comply with the user's 
currently selected preferences. 

4.4 Specific requirements on the UE 

1 . The UE shall have the capability to authenticate the source of the application. 

2. The UE shall have the capability to assure the integrity of an application. 

5 Specific Interaction Requirements 

The following clauses detail specific interaction requirements. 

5.1 Bearer Independent Data Transfer: Radio Access bearers 

Bearer Independent Data Transfer, using bearers over the Uu reference point, is a (U)SAT feature that allows a (U)SAT 
application to request the MT to set up and manage a data channel over a CSD, GPRS, SMS or USSD bearer using 
information provided by the (U)SAT application. Once the call is established, data may be transferred through that data 
call. The details for the (U)SIM-(U)S AT/ME interface are specified in 3GPP TS 31.101 [4], 31.102 [5], and 31.111 [6]. 
The Service Requirements for this are specified in 3GPP TS 22.038 [7]. 

5.1 .1 Interaction between Core MT functions and Bearer Independent 
Data Transfer Service using Radio Access bearers 

When a Bearer Independent Data Transfer Service is requested by a (U)SAT application, the MT shall: 

• If the MT is idle, set up the data channel as requested, indicating to the user by appropriate means, e.g., with an 
icon, that one or more calls are in progress and confirming to the (U)SAT application. 

• If the MT is not idle and can not service the request without negative impact on ongoing services, then the MT shall 
indicate to the (U)SAT application that the data channel can not be set up. However, if the user has indicated a 
preference for servicing such requests despite the negative impact then the MT may proceed as in the bullet point 
above. 

• If the user requests that the call be terminated via MMI or other interface, then the call shall be terminated and the 
(U)SAT application shall be informed. 

• If an external device (TE, Bluetooth device etc.) requests the same resource then that request shall be denied. 

The above behaviour may be modified by a change of user preferences, for example the user may request the MT to 
deny access by the (U)SAT application to a data channel, or the user may request the MT to prioritise a particular 
external device such that a call set up by a (U)SAT application is cleared in order for the external device to be able to 
make a call. 
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5.2 Bearer Independent Data Transfer: local bearers 

Bearer Independent Data Transfer, using local bearers, is a (U)SAT feature that allows a (U)SAT application to request 
the MT to set up and manage a data channel over local links such as Bluetooth, IrDA, RS232 or USB, using information 
provided by the (U)SAT application. Once the channel is open (local link), data may be transferred through the open 
channel. The details for the (U)SIM- (U)SAT/ME interface are specified in 3GPP TS 31.101 [4], 31.102 [5], and 
31.111 [6]. The Service Requirements for this are specified in 3GPP TS 22.038 [7]. 

5.2.1 Interaction between Core ME functions and Bearer Independent 
Data Transfer Service using local bearers 

When a Bearer Independent Data Transfer Service over a local link is requested by a (U)SAT application, the MT shall: 

• If the MT can set up the local channel as requested, the user shall be notified by appropriate means, e.g., with an 
icon, that one or more channels are in progress and confirming to the (U)SAT application. 

• If the MT cannot service the request without negative impact on ongoing services, then the MT shall indicate to the 
(U)S AT application that the data channel cannot be opened. However, if the user has indicated a preference for 
servicing such requests despite the negative impact then the MT may proceed as in the bullet point above. 

• If the user requests that the channel be closed via MMI or other interface, then the channel shall be closed and the 
(U)SAT application shall be informed. 

The above behaviour may be modified by a change of user preferences, for example the user may request the MT to 
deny access by the (U)SAT application to a data channel over a local link, or the user may request the MT to prioritise a 
particular external device such that a channel open by a (U)SAT application is cleared in order for the external device to 
be able to make open a channel. 

5.2.2 Security requirements on (U)SAT Bearer Independent Data Transfer 
using local bearers 

The local link connection, via Bluetooth, IrDA, USB or RS232, set up from a (U)SAT application shall follow the same 
security requirements as if the link were established by an application in the MT. 

It is important that the requirements stated in 5.3 "Services and applications external to the MT" are fulfilled when a 
Bearer Independent Data Transfer via local link bearer is controled by a (U)S AT application. 

The secret key and the authentication algorithm cannot be transferred out from the UICC, where the (U)SAT 
application resides, over the established local link. 

5.3 Services and applications external to the MT 

In the tele- and datacom community there exist today use cases for moving internal interfaces out of the MT; they are 
required to fulfil user expectations of what services and features 3G MTs should offer. 

However, discussions on security clearly show that services should be terminated in the MT, while applications can, as 
today, terminate in the TE. A possible UE functionality split should not allow internal interfaces (including USIM) to be 
moved to external interfaces, neither using USAT local link nor other interfaces. 

This is a precaution that shall be taken until suitable procedures against misuse have been found and standardised. 
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Annex A (informative): 
Interaction handling 



In the present document we illustrate possible types of interaction handling for a MT that already can be required or that 
currently are being developed in standards and industry fora. Although it is probable that only a subset of these entities 
will exist at the same time, there is no way of knowing the particular combination of applications or a particular users 
needs relative to this in advance; a general way to handle the co-existence must still be defined. 

A framework, defining general rules for handling this co-existence of several external functions is outlined in the 
present document. The framework states requirements for the behaviour of the external functions as well as principles 
for the co-existence as such. As an example, several of the external functions below, or protocols used by them (e.g., the 
AT-commands) assume a one-to-one relation between them and the MT Core Functions, implying a lack of specified 
mechanisms to handle a multitask environment. 



A.1 The model approach 



The model below proposes a conceptual split, meaning that the entities and their interfaces are logical and need not 
correspond to any physical division. Before the figure is presented some clarifications and general comments are 
needed: 

• The MT Core Functions should be understood as the (collection of) software functions that contain the central logic 
for the MT, including for instance the scheduling of events. 

• With external event is meant interaction that an application/peripheral wants (requests/commands), as well as 
necessary handling of network signalling, user request via the keys, etc. External does not imply whether an 
external interface is used or not. 

• Some network signalling is easy to refer to basic network functions, such as Location Update, while other 
signalling has been invoked by an application. 

• The user can interact intervene directly via keys, etc. This is indicated with the Manual User Interaction entity. The 
user can of course do the same via, e.g., a PC or a MExE application, but the events that such actions create is here 
viewed like the other events that these entities can create. 

• The USIM general Smart Card Functions are split into several logical entities: the Transport Layer Security, 
meaning "basic" 2G/3G security; the USIM Application Toolkit; USIM Application Toolkit Run AT-command; 
and other functions, such as the WIM, the WAP Identity Module, that is being specified. 

• The TE, Terminal Equipment, is a PC or another piece of equipment that can run applications independently. 

• An Intelligent Peripheral could be an advanced charger or a car hands-free installation. 

• The MExE entities are as defined in [2]. 

• Other includes MT resident applications and allows for future applications, and, if that is needed for the model, 
could correspond to other external devices such as a microphone. 

• The interfaces as shown in the figure are logical. In practice the applications run in the MT, a TA or on its own 
separate platform, and the interfaces are then MT internal or external via a physical connector, IrDA, or Bluetooth. 
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Figure A.I Example of External events that the MT Core Functions should handle 

The figure shows the extent of the complexity that the MT will be expected to handle. It is obvious that a generic 
framework for conflicts, error handling and interactions is needed. In particular, the following issues can be noted: 

1 . Priorities of the event handling - the MT does the scheduling and this should be according to the user' s 
preferences. 

2. User control - the user's wanted / required interaction; his/her knowledge and control of the events; user integrity 
for instance for personal data, the MT position, etc. 

3. Trace-ability - which entity / application has caused a particular event. This information is required input to solve 
several of the other issues. 

4. Consistency - in the actions of the MT Core Functions relative to the specific application. Several applications and 
priority levels interact. 

5. The validity of commands - for instance call validity when the MT is in the Home PLMN or roaming. 

6. Network signalling aspects - how does for instance a dual mode MT treat applications specific to only one of the 
standards. 

7. It might be necessary to look into mechanisms for rejection and termination by the MT Core Function (upon user 
choice) for applications, calls etc. 

8. Testability - the MT manufacturer must be able to as far as possible verify the behaviour of the product, and this 
should be taken into consideration when the framework is specified. Conformance testing, however, is only 
relevant to the extent that already is tested. 

9. Security aspects - for the protection of the MT and the network mechanisms like authentication of the applications 
might be required. 

Further, the entities have different characteristics; this can possibly be used by the framework definitions. The following 
can for instance be noted: 

1. Several of the entities work together with network nodes, some as slaves (e.g., SIM) and others invoking 
commands (e.g., WAP). Others, like the intelligent peripherals, only communicate "locally". 
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2. The entities can be active or passive. In the latter case the MT has more knowledge about the expected behaviour, 
since they only execute functions upon request and cannot issue commands independently. 

3. Some events refer to "basic" network handling, some to manual user interaction, and others relate to application 
invoked functions. "Basic" network interaction should then have priority if such a distinction can be made. 
Consideration should be given to incoming calls. 
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